Authentication and Authorization

What are authentication and authorization?#

To fulfill our security goals, the API needs to be able to differentiate users in our system and potentially fend off nefarious users. Let’s take the example of a banking API. It would be detrimental if we couldn't verify the identity of the individual users utilizing our API, and because of the inability to do so, an imposter gains access to another user’s account and the assets within. Also, not all service users are alike—some might be individual users, while others might belong to a large organization. The authorization mechanism manages what each user is permitted to do based on their user category, such as having the ability to call different functions or make specific number of API calls per day. Therefore, to implement the methods above, authentication and authorization become essential to implementing the security goals we defined earlier in this chapter.

Authentication refers to the procedure through which our API verifies who the user is. Typically, applications fulfill this by implementing a login system utilizing usernames and passwords for verification. There are other techniques for authenticating users in the API paradigm that we’ll explore in this lesson.

Authorization is controlling what the user has access to. This is when applications verify whether the user is even allowed to call the request they are making. For example, we may be authorized to view a Google Doc but not edit it.

Let's begin by defining some common authentication protocols prevalent in the API landscape, after which we'll expand on the frameworks that combine and utilize these protocols to implement both authentication and authorization.

Authentication and authorization mechanisms#

There are several mechanisms we can explore in this section, so let's take a look at those prevalent in today's industry. We'll begin with one that's largely regarded as the simplest, HTTP basic authentication.

HTTP basic authentication#

HTTP basic authentication is a rudimentary scheme that verifies a client through username and password authentication. It encodes the user's username and password in Base64 and embeds it into its Authorization header. The encoding follows a set template. For instance, a client with the username “Bob” and password “thefarmer” will be embedded in the header as follows:

Note: The Authorization request header represents the username and password as Bob:thefarmer encoded in the Base64 format. The Basic keyword before the encoded text signifies that this request header is for basic authentication.

Once entered, this username and password are sent to the server, which verifies the user. This process is illustrated below:

The process is as expanded below:

1. The client forwards a request to the server.

2. The server can't authenticate the client, so it rejects the request and forwards the error message to the client through the WWW-Authenticate response header. Through this header, the client is prompted to enter their username and password.

3. The client then relays the same request, this time with its encoded username and password along with the request in its Authorization header.

4. The server verifies the user and allows the request to go through.

The advantages and disadvantages of HTTP basic authentication are as follows:

This method has largely been discontinued in the API landscape because of the drawbacks mentioned above, so we turn to other authentication protocols.

API keys#

API keys deal with the shortcomings of HTTP basic authentication by replacing the encoded username and password with a generated string. API keys are uniquely generated by the API provider for every consumer/application developer to be used in their applications. It should be noted that API keys are merely strings that identify the application, and they require other security protocols for their secure transmission.

Note: API keys can’t authenticate end users making requests, just the application sending the request. For this purpose, it’s used in tandem with other protocols to implement authentication.

There are various ways in which an application might generate API keys. Some may generate random strings, further encode them, and finally pad with random characters in between. Other APIs increase the number of bits that represent each API key, which reduces both its predictability and increases the number of keys that can be given to applications. No matter what method is used, the goal is to provide unique and unguessable keys.

The following is an example of what an API key may look like:

With API key authentication, the application forwards its assigned API key in the header of its request. When the server receives the said request, it looks up the API key in its database in hopes of verifying the application. An example of API key generation is shown below:

Utilizing API keys over HTTP basic authentication has many benefits:

• Unlike HTTP basic authentication, API keys provide applications the option to have multiple keys per account.

• API keys are deemed more convenient than their counterpart, which can be seen in their ability to refresh and regenerate tokens used as API keys.

• Because the API is separate from the user’s username and password, any security breach will be limited to the API. Even if the attacker has a compromised key, they won’t have the user’s credentials.

• API keys can be revoked if need be, for instance, if the keys are compromised.

It's essential to keep API keys a secret because if an attacker gains access to an API key, the server won't be able to differentiate it from the legitimate user.

The advantages and disadvantages of API keys are as follows:

JSON Web Token (JWT)#

A JSON Web Token (JWT) is an open standard that’s a compact and self-sufficient method for safely transferring data between entities in the form of JSON objects. JWTs are a collection of encrypted strings denoting a header, a payload, and a signature that travel through HTTP requests. Unlike the previous protocols, tokens can be used for both authentication and authorization purposes because they carry information about the token's holder.

JWTs are commonplace in the API landscape, especially with regard to the security protocols we explored earlier in this lesson. An example of a decoded JWT's header is shown below:

The header contains information about the hashing algorithm and the token type. In the case above, HS256 is the hashing algorithm, and the token type is JWT.

Payloads contain statements about the user the token is assigned to, such as its name, issuer, and expiration, among others:

Finally, JWTs additionally include a signature that verifies that the holder of the token is legitimate and that the message hasn't been altered in transmission. To generate the signature, we sign the encoded header, the payload, and a secret (exclusive to the entity generating the JWT) with a hashing algorithm mentioned in the header. The recipient of the JWT will recalculate and compare the two signatures to determine if it was altered during transmission.

An example of signature representation is given below:

Note: Note: The code above is encoded as strings using base64. The header and payload are separated by a period, .. The encoded representation of a token follows the [header].[payload].[signature] template, with the period splitting the header, payload, and signature segments.

Tokens are embedded with a time limit, after which they are rendered invalid, and a new token has to be generated by using refresh tokens or authenticating into the server again. The slides below illustrates the creation and usage of tokens:

The process is as follows:

1. The client sends an authenticate request to the server with their username and password using HTTP authentication. The application validates the request and then creates a token for the client. In the slides above, the username is exampleuser, while the password is password. A token is sent to the client after generation.

2. The token is stored on the client side and is sent through the HTTP Authorization header to the server when requests are made. The Bearer keyword signifies that this authentication scheme is token based, similar to how the Basic keyword earlier signified how basic authentication was being used. This request can be interpreted as requesting access to the bearer of this token.

3. On arrival of the request, the server verifies the token. On successful verification, the server sends an appropriate response back to the client. In the slides, a GET request is put for the client's username, which is returned after verification of the token and the request.

API keys and tokens may seem similar, but there are a few key differences:

• API keys only serve to identify the client, whereas tokens carry more information with them, such as their source, the identifier, and other metadata. This extra information is helpful for authorization purposes.

• Tokens are structured to contain a header and a payload. API keys are just generated strings.

The frameworks discussed in the upcoming lesson will explore the usage of tokens.

The pros and cons of the techniques we explored in this lesson are compiled in the table below:

Before we wrap up, let's take a look at the use cases in which API keys and JWTs may be helpful. In the case of blocking unauthorized traffic to our API, keys should be used because they authenticate the applications making the request. API keys are also used in implementing rate limiting, which controls how many calls a specific application is allowed to an API. They can also be used to filter logs by the specific API key.

In cases where we need secure authorization, JWTs that are used as keys are unable to provide this. This is because JWTs have finer-grained controls as compared to a single key. In projects where we need to identify the end users, JWTs are also preferred because keys only identify the application, not the user making the request.

In this lesson, we've explored various authentication and authorization protocols and their respective advantages and disadvantages. Now, in the following lesson, let's examine how these protocols are incorporated in different frameworks popular in the API landscape to fulfill our API's security goals.